Methods and apparatus for patching software in accordance with instituted patching policies

ABSTRACT

The present invention concerns methods and apparatus for controlling software patching activity in, for example, computer systems. Methods and apparatus of the present invention may implement a software shell and institute a patching policy to control patching activities. When implemented, the software shell acts as a barrier which permits patching of the underlying software only when the patching activity would be in accordance with the instituted patching policy. Various patching policies can be instituted in embodiments of the present invention. For example, patching may be done when convenient; or just before when the software requiring the patch is needed; or patching may be blocked to prevent unwanted software characteristics and/or behavior. In other circumstances, patching may be delayed until confidence has been established in a new patch so as to avoid disrupting a computer system that is already functioning in an acceptable manner. In still further circumstances, a particular software action may be blocked so as to avoid the necessity of having to patch software, particularly when the action may interrupt the orderly function of a computer system.

TECHNICAL FIELD

The present invention generally concerns software patching, and moreparticularly concerns methods and apparatus for implementing bothsoftware patching policies and a software shell that controls patchingactivities so that patching occurs in accordance with institutedpatching policies.

BACKGROUND

Over the past decade or so a paradigm has developed governing howcomplex software including, for example, operating systems andapplication suites, will be updated. Typically, an operating system orapplication suite is released (“goes gold”) and is assigned one or bothof a new name and a version number. Users of the operating system orapplication suite then typically find software faults (“bugs”), a numberof which always seem to survive pre-release testing. Those responsiblefor the operating system or application suite then release a series ofso-called “patches” which eliminate bugs found in the software. For aparticularly complex computer program many such patches may be released.

Patching activity frequently occurs in parallel with identification ofnew and/or enhanced features desired by users of the operating system orapplication suite, or that are rendered necessary or even mandatory bytechnological developments. After enough enhancements are identified,developed and beta-tested, the improved operating system or applicationsuite is released as a new product. So a pattern develops of newrelease, followed by patching activity, followed by new release,followed by patching activity, . . . etc.

When presented with the availability of a new release, users decidewhether new features included in the new software release are needed. Ifnot, the user will not acquire the new release. Often, the situation ismore complicated, with potential users holding back until first adoptersreport their experiences with the new release. If a consensus is reachedin a user community that features of the new release outweigh drawbacksof the new release (such as, for example, unnecessary modifications touser interfaces which need to be learned; slowdown in overallperformance due to increased code size; or overall “buggy” performanceof a heretofore stable program), then those potential users holding backwill purchase the new release.

The same concerns are reflected in decisions about whether to adopt newpatches as they become available. Most user populations are aware ofso-called “horror stories” that accompany the reflexive and unthinkingadoption of any and all software patches. For example, an applicationsuite which previously operated in a responsive manner may now functionin a less-responsive manner due to a resource-intensive software patch.In other situations, the software patch may result ininstability—“crashes”—when code associated with the patch is executed.It is not unusual for some users to have the feeling that they havebecome unwitting members in a beta testing program for the patch.

Such outcomes are particularly troubling when users realizeafter-the-fact that the applied patch concerned “improvements” tofunctionality that they may rarely, or never, use. It is well-known inthe art of computer software that particular users will rarely employall of the functionality of a software system. Rather, the fullfunctionality of a software system is required in order to address across-section of needs reflected in a target market. Accordingly, it isoften the case that a patch may fix a problem in functionality that isseldom, or never, used by a particular user.

When viewed from the perspective of a large corporation, reflexive andunthinking patching activity may result in numerous inefficiencies whenthe activities associated with adopting a patch are aggregated across acorporation. A given patch consumes resources in several ways: it maytake network bandwidth to download, storage space to store andcomputational cycles to install. Often more importantly, the time andenergy of a system user may be needed to decide whether to install thepatch and, if the user decides to do so, to direct installation of thepatch. Decisions about the advisability of installing a patch may dependon information which is not in the user's possession, requiring the userto search for the information. The patch, when installed, may reduce theperformance of the software system, resulting in many users undoing thepatch thereby incurring further inefficiencies.

Thus, those skilled in the art desire improved methods and apparatus forcontrolling software patching activities. In particular, those skilledin the art desire methods and apparatus for implementing control overpatching activities. Further, those skilled in the art desire methodsand apparatus for providing software functionality capable of performingsoftware patching activity in accordance with decisions made about whento patch.

SUMMARY OF THE PREFERRED EMBODIMENTS

A first embodiment of the invention comprises a signal-bearing mediumtangibly embodying a program of machine-readable instructions executableby a digital processing apparatus of an electronic device to performoperations for controlling software patching activities, the operationscomprising: instituting a software patching policy for controllingpatching of software incorporated in the electronic device; and patchingsoftware in accordance with the instituted software patching policy

A second embodiment of the invention comprises a signal-bearing mediumtangibly embodying a program of machine-readable instructions executableby a digital processing apparatus of an electronic device to performoperations for controlling software patching activities, the operationscomprising: implementing a software patch control shell for controllingpatching activities associated with software incorporated in theelectronic device; instituting a software patching policy to be used bythe software patch control shell for controlling software patchingactivities; and applying the software patching policy as potentialsoftware patching opportunities occur.

A third embodiment of the invention comprises a system for managingsoftware patching activity, the system comprising a software patchingactivity manager, the software patching activity manager comprising: atleast one memory to store at least one program of machine-readableinstructions, where the at least one program performs operations forinstituting and controlling a software patching policy; a networkinterface for use in communicating over a network with a source ofsoftware patches and with electronic devices subject to the softwarepatching policy; at least one processor coupled to the at least onememory and network interface, where the at least one processor performsat least the following operations when the at least one program isexecuted: creating a software patching policy to be used by theelectronic devices; and issuing the software patching policy to theelectronic devices through the network interface.

A fourth embodiment of the invention comprises a system for managingsoftware patching activity, the system comprising a software patchingactivity manager, the software patching activity manager comprising: atleast one memory to store at least one program of machine-readableinstructions, where the at least one program performs operations forinstituting and controlling a software patching policy; a networkinterface for use in communicating over a network with a source ofsoftware patches and with electronic devices subject to the softwarepatching policy; at least one processor coupled to the at least onememory and network interface, where the at least one processor performsat least the following operations when the at least one program isexecuted: creating a software patching policy to be used by theelectronic devices; and issuing the software patching policy to theelectronic devices through the network interface.

In conclusion, the foregoing summary of the alternate embodiments isexemplary and non-limiting. For example, one of ordinary skill in theart will understand that one or more aspects or steps from oneembodiment can be combined with one or more aspects or steps fromanother embodiment to create a new embodiment within the scope of thepresent invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other aspects of these teachings are made more evidentin the following Detailed Description of the Preferred Embodiments, whenread in conjunction with the attached Drawing Figures, wherein:

FIG. 1 illustrates the disposition of the elements of a system embodyingthe subject invention;

FIG. 2A is a schematic illustration of a system operating in accordancewith the prior art and FIG. 2B is a schematic illustration of a systemoperating in accordance with the invention;

FIG. 3 is a flow diagram describing the processing performed by thepatch shell;

FIG. 4 depicts a method operating in accordance with the invention;

FIG. 5 depicts another method operating in accordance with theinvention;

FIG. 6 depicts a further method operating in accordance with theinvention; and

FIG. 7 depicts yet another method operating in accordance with thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a system embodying the subject invention. End-userworkstation 1 contains software subject to patching. It is to be notedthat the subject invention does not apply only to end-user workstationsoftware, but to software on servers, software on personal devices andembedded software on dedicated devices such as automobiles, routers andkitchen appliances. A path exists from end-user workstation 1 to theInternet 2, through which communication may be established to patchrepository computer 3 and patch manager computer 4. Server 3 hasattached storage device 8 containing the contents of one or morepatches, while service manager computer 4 has attached storage device 5containing information relating to the circumstances needing a patch.These circumstances are represented as a syndrome of use of a specificsystem component, that syndrome indicative of behavior of the systemcomponent for which a patch exists. For example, suppose that the systemcomponent were the software responsible for communication using theTCP/IP protocol suite, and that there is an error in the implementationof the secure sockets layer (SSL) component of that suite, for which apatch exists. Then the syndrome of use is a particular invocation of theapplication programming interface (API) of the TCP/IP protocol suiteimplementation, such that the invocation initiates communication usingSSL. The syndrome may be as simple as the name of the entry point intothe TCP/IP protocol suite and the values of the arguments passed throughthe entry point.

FIG. 2A is a schematic diagram illustrating a system component operatingin accordance with the prior art and FIG. 2B is a schematic diagramillustrating a system component operating in accordance with the presentinvention. In FIG. 2A is shown a system component 10 with its API. InFIG. 2B is shown a system component 10 with its API, embedded in a newsoftware component, the patch shell 11. The API to the patch shell,shown as API*, is a strict superset of the API to the system component:that is, it contains all of the entry points to the system componentAPI, with some additional entry points. The patch shell 1 1 communicateswith a database of syndromes 12. The features associated with patchshell depicted in FIG. 2B are a particular advantage of the presentinvention and will be described in greater detail.

It can be seen from the figure and the description above that any use ofsystem component 10 can be accomplished with equivalent use of patchshell 11. In fact, some of the entry points to the API of the patchshell may be identical to the entry points to the API of the systemcomponent. Those that are not are said to be “monitored.” Monitored APIcalls are first checked by the patch shell to see if they match anyinvocation syndromes. If they do, it may be the case that this callinvokes behavior for which a patch exists, but where the patch has notyet been applied. Not shown in FIG. 2 is reference by the patch shell toa policy database which controls what to do in this situation.

FIG. 3 is a flow diagram that illustrates the processing performed bythe patch shell. The patch shell is a monitor that is invoked when acall is made to its API; thus it is shown in the figure as executingcontinuously. In block 20 the patch shell waits for the next invocationof a monitored entry point of the system component's API. In block 21the arguments and identity of the entry point are captured, and in thedecision block 22 these are compared to active syndromes for that systemcomponent. If the current call does not match any syndrome, branch 23 istaken to block 24 which makes the equivalent call directly to the systemcomponent's API, and then block 20 is re-entered to wait for the nextcall.

If the current call does match an active syndrome, branch 25 is taken todecision block 26 which determines the policy for that syndrome. If thepolicy is to do nothing, branch 27 is taken to block 24 previouslydescribed. If the policy is to block the API call branch 30 is taken toblock 20, effectively ignoring the API call. If the policy is to patch,branch 28 is taken to block 29 which installs the necessary patch. Whenthat installation is complete, block 24 is entered, as previouslydescribed.

Many forms of this invention are possible. In a preferred form,syndromes, patch shells, policies and patches are installed and managedby a service. As previously noted, the invention applies to all types ofcomputing devices. The invention is not limited to the policies givenhere. In particular, a policy may be to notify an end user oradministrator to get their input before installing the patch. Patchesmay be applied if there are more than k invocations of the behavior,where k is a parameter.

Alternate methods operating in accordance with the present inventionwill now be described with reference to FIGS. 4-7. FIG. 4 depicts amethod 400 generally applicable to an electronic device having asoftware suite requiring occasional patching. At step 410, a digitalprocessing apparatus incorporated in the electronic device executes asoftware program that institutes a software patching policy forcontrolling patching of software comprising the software suite. Thecomputer program implementing the software patching policy typicallyruns continuously. When an opportunity for patching the softwarecomprising the software suite arises, the computer program patches thesoftware in accordance with the software patching policy at step 420.

In one variant of the method depicted in FIG. 4, the software patchingpolicy allows a particular software patch to be implemented only if itis established that a user of the electronic device actually uses asoftware feature that requires the particular software patch. In anothervariant of the method depicted in FIG. 4, the software patching policyallows a particular software patch to be implemented only at times thatare convenient for the user of the electronic device. In a furthervariant of the method depicted in FIG. 4, a software patch will beimplemented on as-needed basis. In other words, application of aparticular software patch will be held in abeyance until a time when auser of the electronic device has indicated that a software featurewhich requires the particular software patch will be used for a firsttime since the issuance of the particular software patch.

In yet another variant of the method depicted in FIG. 4, the softwarepatching policy is instituted on a category basis, wherein certaincategories of software patches will be implemented and certaincategories of software patches will be blocked.

In a still further variant of the method depicted in FIG. 4 additionalsteps are performed. In one additional step, information is receivedthat a particular patch which is otherwise desirable has a deleteriouseffect on operations of the electronic device only when a particularsoftware feature is used. In another step, the implementation of theparticular software patch is permitted. In a still further step, use ofthe particular software feature which causes the deleterious effect whenusing software which has implemented the particular patch is blocked.

In another variant of the method depicted in FIG. 4, if it is determinedthat a particular software patch will not be implemented, then anadditional step is performed to block use of the software featurerequiring the particular patch. This aspect of the present invention canbe used when both the present state of the software without the patchand the patch itself are particularly problematic. For instance, neitherthe un-patched software feature nor the patch may operate in asatisfactory fashion.

In a further variant of the method depicted in FIG. 4, the softwarepatching policy that is implemented at 410 may permit a second softwarepatch to be substituted for a first software patch. This willaccommodate situations where an improved patch has been developed as asubstitute for a patch that has already been approved for installation.

Another method 500 capable of operating in accordance with the presentinvention is depicted in FIG. 5. The method depicted in FIG. 5 isintended for use by an electronic device having a software suite whichrequires occasional patching. When the method is incorporated in acomputer program and the computer program executed the operationsdepicted in FIG. 5 are performed. At step 510, the computer programembodying the method implements a software patch control shell forcontrolling software patching activities associated with softwareincorporated in an electronic device. Next, at step 520, a softwarepatching policy to be used by the software patch control shell forcontrolling software patching activities is instituted. Then, at step530, the software patch control shell applies the software patchingpolicy as software patching events occur. Generally, software patchingevents occur as a source of software patches issues new softwarepatches. Various software patching policies may be implemented in themethod depicted in FIG. 5, including policies similar to those describedwith respect to FIG. 4.

A further method 600 depicted in FIG. 6 is intended for use by asoftware patching activity manager like the patch manager 4 depicted inFIG. 1. In the method at step 610, the software patching activitymanager institutes a software patching policy to be used by electronicdevices accessible over a network in deciding whether to implement apatch. Then at step 620, the software patching activity manager makesthe software patching policy available to the electronic devices overthe network. Next, at step 630, the software patching activity managermonitors a source of software patches. Then, at step 640, the softwarepatching activity manager examines a particular patch issued by thesource of software patches to determine whether the patch is permittedunder the software patching policy. Next, at step 650, the softwarepatching activity manager issues an advisory message to the electronicdevices over the network indicating circumstances in which theparticular patch issued by the source of software patches should beimplemented.

In variants of the method depicted in FIG. 6, various software patchingpolicies may be implemented similar to those described with respect toFIGS. 4 and 5.

Yet another method operating in accordance with the present invention isalso intended for use by a software patching activity manager like patchmanager 4 depicted in FIG. 1. In the method 700 depicted in FIG. 7, thesoftware patching activity manager creates a software patching policy tobe used by electronic devices having software suites that requireoccasional patching at step 710. Then, at step 720, the softwarepatching activity manager issues the software patching policy to theelectronic devices over a network.

In a variant of the method depicted in FIG. 7, the step of creating asoftware patching policy further comprises additional steps. In a firstadditional step, the software patching activity manager analyzes patchesavailable at the source of software patches. Then, in another step, thesoftware patching activity manager determines which patches should beinstituted in the electronic devices subject to the software patchingpolicy. In other variants, determining which patches should beinstituted in the electronic devices subject to the software patchingpolicy comprises additional steps. These steps may comprise gatheringinformation concerning operational experiences with patches available atthe source of software patches; and adopting particular software patchesfor implementation by the electronic devices subject to the patchingpolicy only if operational experiences with particular patches meet atleast one predetermined criterion. Many predetermined criteria may beadopted in accordance with the invention such as, for example, a maximumacceptable number of faulty installations of the patch to be expected ifthe patch is adopted, a maximum acceptable number of new but undesirablebehaviors that the patched software now exhibits; a maximum acceptabletime required to install the software patch; maximum acceptable level ofresources required to implement the patch, etc.

In another variant of the method depicted in FIG. 7 the followingadditional operations are performed: monitoring the source of softwarepatches for new patches as new patches become available; detecting a newpatch; examining the new patch issued by the source of software patchesto determine whether the patch is permitted under the software patchingpolicy; and issuing an advisory message to the electronic devicesindicating circumstances in which the new patch issued by the source ofsoftware patches should be implemented, if at all. Before issuing anadvisory message, still further steps may be taken in this variant ofthe method depicted in FIG. 7. In one such variant the followingadditional operations are performed: before issuing the advisorymessage, monitoring sources reporting experiences with the new patch;and issuing an advisory message allowing implementation of the newsoftware patch in the electronic devices subject to the patching policyonly if reported experiences with the new patch meet at least onepredetermined criterion. In another such variant the followingadditional operations are performed: before issuing the advisorymessage, performing a cost-benefit analysis of the new patch bycomparing costs and benefits associated with implementation of the newpatch; and issuing an advisory message allowing implementation of thenew software patch in the electronic device only if the new patch meetsat least one predetermined cost-benefit criterion. Various cost-benefitcriteria may be used such as, for example, user time necessary toimplement the new patch; cost of bandwidth necessary to download the newpatch; storage space required to store the new patch; and user timenecessary to undo the new patch if the patch is determined to be faulty.

One of ordinary skill in the art will understand that the methodsdepicted and described herein can be embodied in a tangiblemachine-readable memory medium. A computer program fixed in amachine-readable memory medium and embodying a method or methods of thepresent invention perform steps of the method or methods when executedby a digital processing apparatus coupled to the machine-readable memorymedium. Tangible machine-readable memory media include, but are notlimited to, hard drives, CD- or DVD-ROM, flash memory storage devices orin a RAM memory of a computer system.

Thus it is seen that the foregoing description has provided by way ofexemplary and non-limiting examples a full and informative descriptionof the best method and apparatus presently contemplated by the inventorsfor patching software in accordance with instituted patching policies.One skilled in the art will appreciate that the various embodimentsdescribed herein can be practiced individually; in combination with oneor more other embodiments described herein; or in combination withcomputer systems differing from those described herein. Further, oneskilled in the art will appreciate that the present invention can bepracticed by other than the described embodiments; that these describedembodiments are presented for the purposes of illustration and not oflimitation; and that the present invention is therefore limited only bythe claims which follow.

1. A signal-bearing medium tangibly embodying a program ofmachine-readable instructions executable by a digital processingapparatus of an electronic device to perform operations for controllingsoftware patching activities, the operations comprising: instituting asoftware patching policy for controlling patching of softwareincorporated in the electronic device; and patching software inaccordance with the instituted software patching policy.
 2. Thesignal-bearing medium of claim 1 wherein the software patching policyallows a particular software patch to be implemented only if it isestablished that a user of the electronic device actually uses asoftware feature that requires the particular software patch.
 3. Thesignal-bearing medium of claim 1 wherein the software patching policyallows a particular software patch to be implemented only at a time thatis convenient for a user of the electronic device.
 4. The signal-bearingmedium of claim 1 where the software patching policy allows a particularpatch to be implemented only at a time when a user of the electronicdevice has indicated that a software feature which requires theparticular software patch will be used for a first time since theparticular patch became available.
 5. The signal-bearing medium of claim1 where the software patching policy is instituted on a category basis,wherein certain categories of software patches will be implemented andcertain categories of software patches will be blocked.
 6. Thesignal-bearing medium of claim 1 where the operations further comprise:receiving information that a particular patch which is otherwisedesirable has a deleterious effect on operations of the electronicdevice only when a particular software feature is used; permittingimplementation of the particular patch; and blocking use of theparticular software feature which causes the deleterious effect whenusing software which has implemented the particular patch.
 7. Thesignal-bearing medium of claim 1 whereby a particular software featurerequires a particular software patch and wherein patching software inaccordance with the instituted software patching policy furthercomprises: blocking application of the particular software patch; andblocking use of the particular software feature that required theparticular software patch.
 8. The signal-bearing medium of claim 1wherein patching software in accordance with the instituted softwarepatching policy further comprises: detecting an opportunity to perform asoftware patching operation; requesting a first software patch from asource of software patches; receiving a second software patch from thesource of software patches as a substitute for the first software patch;and implementing the second software patch if it accords with theinstituted software patching policy.
 9. The signal-bearing medium ofclaim 8 wherein the second software patch is a later version of thefirst software patch.
 10. A signal-bearing medium tangibly embodying aprogram of machine-readable instructions executable by a digitalprocessing apparatus of an electronic device to perform operations forcontrolling software patching activities, the operations comprising:implementing a software patch control shell for controlling patchingactivities associated with software incorporated in the electronicdevice; instituting a software patching policy to be used by thesoftware patch control shell for controlling software patchingactivities; and applying the software patching policy as potentialsoftware patching opportunities occur.
 11. The signal-bearing medium ofclaim 10 wherein the software patch control shell and softwareincorporated in the electronic device subject to the software patchcontrol shell have the same application program interface.
 12. Thesignal-bearing medium of claim 10 wherein applying the software patchingpolicy further comprises: at the software patch control shell detectinga particular syndrome of software operations that is planned forexecution by the software subject to the software patch control shell;delaying execution of the particular syndrome of software operations bythe software subject to the patch control shell until a decision is madewhether to patch the software that will execute the particular syndromeof software operations; comparing the syndrome of software operations toat least one syndrome for which a software patch is known to exist; ifit is detected that a patch exists for the particular syndrome ofsoftware operations, deciding whether to implement the software patch,wherein the decision is made in accordance with the software patchingpolicy; and patching the software if patching is permitted by thesoftware patching policy.
 13. The signal-bearing medium of claim 12wherein the operations further comprise: allowing the software subjectto the software patch control shell to execute the particular syndromeof software operations after the patch has been implemented.
 14. Thesignal-bearing medium of claim 10 wherein the software patching policyallows a particular software patch to be implemented only if it isestablished that s user of the electronic device actually uses asoftware feature that requires the particular patch.
 15. Thesignal-bearing medium of claim 10 wherein the software patching policyallows a particular software patch to be implemented only at a time thatis convenient for a user of the electronic device.
 16. Thesignal-bearing medium of claim 10 wherein the software patching policyallows a particular patch to be implemented only at a time when a userof the electronic device has indicated that a software feature whichrequires the particular software patch will be used for a first timesince the particular patch became available.
 17. The signal-bearingmedium of claim 10 where the software patching policy is instituted on acategory basis, wherein certain categories of software patches will beimplemented and certain categories of software patches will be blocked.18. The signal-bearing medium of claim 10 where the operations furthercomprise: receiving information that a particular patch which isotherwise desirable has a deleterious effect on operations of theelectronic device only when a particular software feature is used;permitting implementation of the particular patch; and blocking use ofthe particular software feature which causes the deleterious effect whenusing software which has implemented the particular patch.
 19. Asignal-bearing medium tangibly embodying a program of machine-readableinstructions executable by a digital processing apparatus of anelectronic device to perform operations for instituting and controllinga software patching policy, the operations comprising: instituting asoftware patching policy to be used by electronic devices accessibleover a network; making the software patching policy available to theelectronic devices over the network; monitoring a source of softwarepatches; examining a particular patch issued by the source of softwarepatches to determine whether the patch is permitted under the softwarepatching policy; and issuing an advisory message to the electronicdevices over the network indicating circumstances in which theparticular patch issued by the source of software patches should beimplemented.
 20. The signal-bearing medium of claim 19 wherein thesoftware patching policy allows a particular software patch to beimplemented only if it is established that a particular user of anelectronic device potentially subject to the particular patch actuallyuses a software feature that requires the particular software patch. 21.The signal-bearing medium of claim 19 wherein the software patchingpolicy allows a particular software patch to be implemented only at atime that is convenient for a user of the electronic device.
 22. Thesignal-bearing medium of claim 19 wherein the software patching policyallows a particular software patch to be implemented only at a time whena user of a particular electronic device has indicated that a softwarefeature which requires the particular software patch will be used for afirst time since the particular software patch became available.
 23. Asystem for managing software patching activity, the system comprising asoftware patching activity manager, the software patching activitymanager comprising: at least one memory to store at least one program ofmachine-readable instructions, where the at least one program performsoperations for instituting and controlling a software patching policy; anetwork interface for use in communicating over a network with a sourceof software patches and with electronic devices subject to the softwarepatching policy; at least one processor coupled to the at least onememory and network interface, where the at least one processor performsat least the following operations when the at least one program isexecuted: creating a software patching policy to be used by theelectronic devices; and issuing the software patching policy to theelectronic devices through the network interface.
 24. The system ofclaim 23 wherein creating a software patching policy further comprises:analyzing patches available at the source of software patches; anddetermining which patches should be instituted in the electronic devicessubject to the software patching policy.
 25. The system of claim 24wherein determining which patches should be instituted furthercomprises: gathering information concerning operational experiences withpatches available at the source of software patches; and adoptingparticular software patches for implementation by the electronic devicessubject to the software patching policy only if operational experienceswith particular patches meet at least one predetermined criterion. 26.The system of claim 23 wherein the operations further comprise:monitoring the source of software patches for new patches as new patchesbecome available; detecting a new patch; examining the new patch issuedby the source of software patches to determine whether the patch ispermitted under the software patching policy; and issuing an advisorymessage to the electronic devices over the network indicatingcircumstances in which the new patch issued by the source of softwarepatches should be implemented, if at all.
 27. The system of claim 26wherein the operations further comprise: before issuing the advisorymessage, monitoring sources reporting experiences with the new patch;and issuing an advisory message allowing implementation of the newsoftware patch in the electronic devices only if reported experienceswith the new patch meet at least one predetermined criterion.
 28. Thesystem of claim 26 wherein the operations further comprise: beforeissuing the advisory message, performing a cost-benefit analysis of thenew patch by comparing costs and benefits associated with implementationof the new patch; and issuing an advisory message allowingimplementation of the new software patch in the electronic device onlyif the new patch meets at least one predetermined cost-benefitcriterion.
 29. The system of claim 28 wherein a cost associated withimplementation of the software patch analyzed by the software patchingactivity manager is selected from the group comprised of: user time toimplement the new patch; cost of bandwidth to download the new patch;storage space required to store the new patch; and user time necessaryto undo the new patch if the patch is determined to be faulty.
 30. Thesystem of claim 23 wherein the software patching policy allows latersoftware patches to be substituted for earlier software patches.
 31. Thesystem of claim 23 further comprising an electronic device subject tothe software patching policy, the electronic device further comprising:at least one memory to store at least one program of machine-readableinstructions, where the at least one program performs operations forimplementing the software patching policy issued by the softwarepatching activity manager; a network interface for use in communicatingover a network with the software patching activity manager and thesource of software patches; at least one processor coupled to the atleast one memory and the network interface, where the at least oneprocessor performs at least the following operations when the at leastone program is executed: receiving the software patching policy issuedby the software patching activity manager; and performing softwarepatching activities of software incorporated in the electronic device inaccordance with the software patching policy issued by the softwarepatching activity manager.
 32. The system of claim 31 wherein theoperations performed by the at least one processor of the electronicdevice when the at least one program is executed further comprises:implementing a software patch control shell for controlling softwarepatching activities associated with the software incorporated in theelectronic device.
 33. The system of claim 32 wherein performingsoftware patching activities further comprises: at the software patchcontrol shell detecting a particular syndrome of software operationsthat is planned for execution by the software subject to the softwarepatch control shell; delaying execution of the particular syndrome ofsoftware operations by the software subject to the software patchcontrol shell until a decision is made whether to patch the softwarethat will execute the particular syndrome of software operations;comparing the syndrome of software operations to at least one syndromefor which a software patch is known to exist; if it is detected that asoftware patch exists for the particular syndrome of softwareoperations, deciding whether to implement the software patch, whereinthe decision is made in accordance with the software patching policy;and patching the software if patching is permitted by the softwarepatching policy.
 34. The system of claim 33 wherein the operationsfurther comprise: allowing the software subject to the software patchcontrol shell to execute the particular syndrome of software operationsafter the patch has been implemented.